Media content streaming is becoming more popular over the Internet and recent research shows that streaming traffic constitutes the biggest percentage of the overall Internet traffic today and it is expected that this percentage will grow in the future as mobile devices (typically, smart phones) are used increasingly for mobile streaming services. With an increasing number of mobile phone users experiencing mobile streaming, there is a need for streaming optimizations so that streaming experience on mobile devices is improved.
There are currently several streaming technologies designed to operate efficiently over time-varying mobile communications channels, for example, HTTP Live Streaming (HLS) and 3GPP Dynamic Adaptive Streaming over HTTP (DASH). An article entitled ‘Apple proposes HTTP streaming feature as IETF standard’ (retrievable via http://arstechnica.com/web/news/2009/07/apple-proposes-http-streaming-feature-as-a-protocol-standard.ars) gives a brief overview of HLS and DASH is described in 3GPP Technical Specification TS 26.247 (v10.0.0), entitled ‘Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)’.
HLS and DASH support media streaming over a single communication path (or a single radio access technology connection) and adaptive streaming by switching the rate of the encoded media content to match the available transport capacity. With these technologies, the client retrieves the media content as a sequence of small “chunks” of constant duration (typically, near to 10 s). Each chunk can be selected from a plurality of chunks available for the same portion of the media content, e.g. a portion of media content may be represented by a high quality chunk, medium quality chunk, etc. The high quality chunk will have more information and so will be greater in size than the medium quality chunk. Every time the client retrieves a chunk, it measures the retrieval duration. When the duration exceeds a certain threshold (or when other implementation triggers apply), the client requests the next chunk with reduced quality and thus with reduced size that can be retrieved faster. This way, even when the capacity of the transport channel is reduced (e.g. due to channel variations and transmission effects), the streaming flow can be sustained, albeit with reduced quality.
An advantage of HLS/DASH mechanisms is that the streaming flow dynamically adapts to the available transport capacity and features considerable robustness and reliability in mobile communication systems. A disadvantage however is that the adaptation is performed at the expense of quality: when the transport channel deteriorates and cannot support high data rate, the streaming flow is sustained but with reduced quality. For example, when a mobile device uses HLS or DASH to stream a video content over WiFi, the stream content will switch to low quality when the WiFi network gets congested (e.g., when it cannot support TCP throughput of more than 100-200 Kbps) and cannot support the high quality stream. This has a negative effect on the user experience.
Thus, HLS and 3GPP DASH provide efficient and adaptive technologies for mobile media streaming, but they cannot maintain high quality streaming experience when the transport channel deteriorates significantly.
In an effort to improve the video streaming performance, several publications propose the use of multiple simultaneous IP interfaces to retrieve video chunks in parallel. For example, in an article entitled ‘Improving Internet Video Streaming Performance by Parallel TCP-based Request-Response Streams’ by Robert Kuschnig, Ingo Kofler and Hermann Hellwagner (retrievable via http://alvand.basu.ac.ir/˜nassiri/courses/AdvNetworks/papers/paper25.pdf), the authors propose a request-response-based client-driven streaming system, much similar to HLS/DASH, which however uses multiple interfaces to simultaneously retrieve multiple chunks. The reported performance results indicate that multipath chunk retrieval can provide an overall TCP throughput that is relatively stable over a vast range of round trip time (RTT) values and much higher compared to single path chunk retrieval. In this publication, however, the mobile device keeps multiple interfaces continuously active. As a result, such multipath streaming mechanisms can have a considerable negative impact on battery consumption.
Another known technology that can be used for enhanced streaming experience is Multipath TCP (MPTCP) (see, for example, the Multipath TCP Internet drafts which are retrievable via http://tools.ietf.org/wg/mptcp/).
With MPTCP, the client and the server establish multiple, parallel TCP connections (typically over different communication technologies) which are simultaneously used to retrieve the media content. The advantage is that MPTCP can provide increased overall throughput by exploiting the available capacity over multiple communication paths. So, when a HTTP streaming session is conducted on top of MPTCP, the overall transport capacity can be increased and thus improved streaming experience is expected since low-quality media chunks will rarely be required. A disadvantage however is that both the client and the server must be upgraded to support MPTCP which in most cases can be impractical. To alleviate this issue an MPTCP proxy can be used between the client and the server as proposed in a presentation entitled ‘mptcp proxies’ by Mark Handley (retrievable via www.ietf.org/proceedings/80/slides/mptcp-4.ppt). In this case, only the client and the proxy need to support MPTCP and not the streaming/media servers. Yet, there is still a requirement to upgrade the network infrastructure. Also, the use of proxies (or other middle boxes) breaks the end-to-end transparency and can create several issues, e.g., with applications that carry transport information in the payload (FTP, SIP, RTSP, etc). In addition, with MPTCP it is the server that performs the transmission scheduling (i.e., the allocation of media data to the available communication paths or TCP sub-flows) and therefore, the client cannot decide which path or radio access technology to use. This is an additional disadvantage because the server may choose to send data over the most expensive communication path and the client has no power to avoid or otherwise control this behaviour.